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The  first  revision  of  "Embedded  Computer  Resources  and  the  DSARC  Process"  reflects 
comments  of  those  who  used  and  reviewed  the  original  1977  edition.  It  contains  an 
expanded  references  section  and  the  definitions  of  specialized  terms  have  been  added. 

Computer  resources  have  clearly  become  a  subsystem  of  major  significance  to  most  all 
defense  systems.  The  annual  investment  by  the  DoD  is  measured  in  the  billions  of  dollars 
Since  the  greater  portion  of  these  dollars  are  in  the  operation  and  support  phase  of  the  life 
cycle,  it  is  important  to  manage  the  upstream  decisions  to  minimize  their  later  impacts. 
Particular  emphasis  is  given  to  standardization  policies  for  high  order  programming 
languages  and  instruction  set  architectures  which  have  been  established  from  the  DoD 
level. 

Copies  are  being  widely  distributed  throughout  the  DoD  acquisition  community  to  the 
Program-Manager  level  and  to  the  Headquarters  elements  responsible  for  program 
reviews.  Staff  elements  of  the  Office  of  the  Secretary  of  Defense  should  use  the 
guidebook  in  preparation  for  Defense  Systems  Acquisition  Review  Council  milestone 
activity.  It  is  our  desire  that  the  Military  Departments  adapt  and  tailor  the  guidebook  to 
their  special  needs  for  regular  Major  Command  or  Service  System  Acquisition  Review 
Council  (SSARC)  reviews.  It  should  also  be  of  value  in  preparation  of  Inspector  General 
and  Defense  Audit  Agency  checklists. 

H.  MARK  GROVE 
Deputy  bireator 
MaterielSAe^uisition  Policy 
(Embedded  Computer  Resources 
&  Electronics) 
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SECTION  I 


INTRODUCTION 


The  purpose  o!  this  guidebook  is  to  provide  guidelines  to  assess  the  adequacy  ol 
embedded  computer  resource  planning  and  utilization.  The  level  of  Defense  System 
Acquisition  Review  Council  (DSARC)  interest  in  embedded  computer  resources  is  related 
both  to  the  percentage  of  development,  acquisition,  and  support  funds  represented  and  to 
the  criticality  of  system  performance  and  support  that  these  resources  represent. 

Sections  11,  III,  and  IV  address  issues  on  Milestone  I,  II,  and  III  respectively  and  are 
based  on  the  three  major  DSARC  meetings.  DSARC  reviews  are  normally  required  for  all 
defense  systems  designated  by  the  Secretary  of  Defense  as  ”major"  usually  involving  over 
$100  million  (FY80  dollars)  in  research,  development,  test  and  evaluation  or  over  $500 
million  (FY80  dollars)  in  production.  (See  DoD  Directive  5000.1  and  DoD  Instruction 
5000.2  for  further  details.)  In  this  guidebook,  the  term  "defense  system"  implies  either 
major  or  less-than-major  systems  which  are  not  principally  of  an  "ADPE"  nature. 
Milestone  I,  II,  and  III  reviews  are  held  prior  to  entering  the  demonstration  and  validation 
phase,  the  full-scale  engineering  development  phase,  and  the  production  and  deployment 
phase,  respectively.  After  the  reviews,  the  Secretary  of  Defense  decides  if  the  system 
should  proceed  to  the  next  phase.  Sections  I,  II,  and  III  emphasize  embedded  computers 
(i.e.  those  computers  integral  to  weapon  systems  from  a  design,  acquisition,  operations, 
and  dedicated  support  viewpoint)  rather  than  general  purpose  computers  that  may  be  used 
to  provide  incidental  support  for  some  systems.  Major  computer  resources  issues  will  be 
determined  by  the  system  application;  that  is,  high-unit-cost,  low-production  quantity 
systems  may  have  quite  different  issues  than  low-unit-cost,  high-production-quantity 
systems.  Each  of  the  three  sections  consists  of  a  series  of  questions  of  concern  to  Office 
of  the  Secretary  of  Defense  (OSD)  personnel  prior  to  Milestones  1,  II,  and  III.  The  OSD 
staff  may  ask  similar  questions  at  review  meetings  held  prior  to  convening  of  the  DSARC. 
DSARC  principals  should  be  thoroughly  briefed  by  their  staff  on  critical  management 
issues  identified  by  using  these  questions. 

Section  V  is  a  series  of  definitions  of  computer  resources  terms.  They  are  presented 
in  an  attempt  to  achieve  common  terminology  throughout  the  embedded  computer 
community. 

Section  VI  contains  a  matrix  that  details  available  regulations  and  standards  that 
pertain  to  various  computer  resource  topics.  References  are  listed  by  issuing  group 
immediately  following  the  matrix.  Miscellaneous  references,  including  management 
guidebooks  that  have  been  published  by  the  Air  Force  Aeronautical  Systems  Division  and 
Electronic  Systems  Division,  are  also  listed  in  this  section. 

Section  VII  contains  a  form  which  can  be  used  to  provide  feedback  suggestions  to 
improve  this  guidebook.  Such  information  will  be  utilized  when  the  guidebook  is  updated. 
If  a  guidebook  update  workshop  is  given  prior  to  the  next  revision,  information  on  the 
workshop  will  be  sent  to  all  those  who  have  submitted  Guidebook  Feedback  Forms.  We 
sincerely  urge  you  to  complete  the  form  and  return  it  with  ycur  comments  on  this  guide. 


SECTION  II 


MILESTONE  I  (DEMONSTRATION  AND  VALIDATION  DECISION) 


The  Milestone  I  decision  point  is  reached  when  the  exploration  of  alternative 
systems  concepts  phase  has  been  completed,  the  Mission  Element  Need  Statement  (DoDD 
5000.1)  approved,  and  selected  alternatives  warrant  system  demonstration.  The  period 
prior  to  Milestone  I  (Concept  Exploration)  is  particularly  critical  relative  to  embedded 
computer  decisions.  The  establishment  of  data  rights,  choice  of  High  Order  Language, 
choice  of  Instruction  Set  Architecture,  and  overall  embedded  computer  resource 
acquisition  strategy  must  be  largely  decided  prior  to  Milestone  I. 

Candidate  acquisition  strategies  should  also  be  developed  prior  to  Milestone  I.  A 
basic  decision  as  to  the  applicability  of  DoD  Directive  5100.40  should  have  been  made  and, 
if  applicable,  steps  taken  to  comply  with  Public  Law  89-306  on  coverage,  exemption,  or 
waiver. 


General  Issues 


1.  What  are  the  embedded  computer  requirements  and  software  items  that  have  been 
identified  at  the  outset? 

2.  What  steps  are  being  made  to  insure  software  management  visibility? 

3.  With  what  other  systems  will  the  system  have  to  interface?  Will  any  interfaces 
change  during  system  development?  What  knowledge  of  system  implementation  of 
the  external  system  is  required?  Is  this  information  available?  How  will  both 
national  and  international  interoperability  and  standardization  be  demonstrated? 

4.  Will  more  than  one  agency  or  contractor  develop  software  for  the  system?  If  so, 
who  will  coordinate  necessary  arrangement  and  technical  interchange  among  them, 
and  when  necessary  arbitrate  disputes  among  them?  Will  the  groups  participate  in 
each  other’s  critical  design  reviews?  How  will  software  integration  be  managed? 

5.  What  is  the  overall  software  maintenance  concept?  What  special  tools  and  facilities 
are  required  to  support  this  concept? 

6.  How  will  requirement  specifications  be  developed? 

7.  Who  will  perform  analysis  for  reliability  and  maintainability,  and  perform  independ¬ 
ent  quality  and  reliability  assessments  (DoDD  4155.1)? 

8.  What  design  reviews  are  planned  during  the  life  cycle?  What  agency  has  overall 
responsibility  for  the  scheduling  and  conduct  of  design  reviews?  Will  reviews  be 
conducted  in  accordance  with  MIL-STD-1521A,  or  another  standard? 

9.  How  will  the  system  requirements  and  design  be  validated  prior  to  implementation? 
How  will  the  system  design  be  evaluated  for  feasibility? 


10.  To  what  extent  should  metric  measurements  be  used  in  new  equipment  (DoDD 
4120.18)? 


Program  Manager's  Staff 


1.  What  percentage  of  development  costs  will  be  spent  on  computer-related  expenses? 

2.  How  many  dedicated  program  personnel  are  skilled  in  computers  and  software? 
What  percentage  of  the  staff  does  this  represent? 

3.  How  many  dedicated  program  personnel  have  had  operational  experience  in  the 
project  application  area? 

4.  What  plans  have  been  made  to  obtain  computer  personnel  temporarily  from  Federal 
Contractor  Research  Centers,  Service  laboratories,  and  support  activities?  From 
private  consulting  firms? 

5.  Who  in  the  Program  Office  (PO)  has  overall  responsibility  for  software  acquisition  or 
for  coordinating  requirements  with  the  acquisition  agency?  Who  will  develop  the 
advanced  acquisition  plan  for  the  Program  Manager? 

6.  Does  the  Program  Manager  (PM)  have  an  experienced  system  engineer  agent 
responsible  for  overseeing  software  systems  engineering? 

7.  How  will  the  PM  provide  for  computer  resources  support  requirements?  Is  there  a 
dedicated  Software  Support  Agency?  How  will  PM  and  agency  roles  be  defined? 

S.  What  type  of  tracking  scheme  will  the  PO  use  to  assure  meeting  milestone  dates? 
What  procedures  will  be  used  to  provide  cost  visibility  to  embedded  computer 
resources?  How  will  these  cost  be  tracked? 

9.  How  will  software  design  maturity  and  supportability  be  quantitatively  assessed? 

10.  What  is  the  scope  of  the  Independent  Verification  and  Validation  (IV&V)  effort?  To 
whom  will  the  IV&V  organization  report?  How  will  the  funding  be  handled?  If 
performed  by  a  contractor,  when  will  the  contract  be  let? 

Operational  Requirements 


1.  When  will  computer  resource  requirements  be  validated?  When  and  how  will  the 
computer  resource  requirements  be  allocated  to  software  and  hardware? 

2.  Are  the  system  operational  requirements  well  defined?  Have  they  stabilized?  Are 
they  realistic?  How  can  this  be  proven?  Are  the  operational  requirements 
testable? 

3.  What  are  the  areas  of  greatest  risk?  How  will  risk  analysis  be  performed? 

4.  Which  operational  requirements  are  likely  to  change  during  development  of  the 
system?  During  system  deployment?  Will  the  software  accommodate  these 
changes?  Are  the  changes  specified  clearly?  What  is  the  planned  method  of 
interface  management  and  control? 

3.  What  are  the  critical  computational  and  decision  algorithms?  What  are  the  plans  for 
validating  these  algorithms  and  the  timing  assumptions  of  these  algorithms? 
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6.  How  will  changes  in  operational  requirements  be  managed  and  controlled?  How  will 
changes  in  software  requirements  be  controlled? 

7.  What  are  the  security  and  privacy  requirements  for  the  system?  How  will  these 
requirements  be  met? 

Life  Cycle  Management 


1.  Has  the  Logistics  Support  Analysis  been  planned  for  the  embedded  computer 
hardware  and  software? 

2.  Does  the  system  life  cycle  support  activity  match  the  software  and  hardware  life 
cycle  requirements? 

3.  How  will  the  software  responsibility  be  transferred,  from  the  developer  to  the 
support  activity  or  user?  What  will  be  the  process  employed  by  the  software 
support  activity  or  the  user  to  update  or  otherwise  maintain  the  software? 

4.  Will  Operations  and  Maintenance  funds  (or  Producability  Engineering  and  Planning 
funds)  be  requested  to  support  contractor  activities  directed  toward  providing 
training,  maintenance  capabilities,  and  documentation? 

5.  Who  will  perform  design  reviews  for  quality  and  for  reliability  and  maintainability? 

6.  How  and  when  will  maintenance  provisions  be  specified? 

7.  Has  the  funding  for  the  integrated  support  resources  been  identified? 

8.  How  will  initial  support  requirements  for  spares  and  spare  parts  be  determined?  Is 
software  support  documentation  specifically  addressed  and  funded? 

9.  What  computer  hardware  will  be  unique?  What  computer  hardware  will  require 
development?  Why  can*t  standard  hardware  be  used?  How  will  replacement  parts  be 
obtained?  Is  there  a  similar  system  in  another  Service  that  can  be  adopted? 

10*  How  will  the  firmware  support  requirements  be  established  during  the  firmware 
development  phase  of  the  program?  What  documentation  for  firmware  is  contract 
deliverable  with  the  firmware? 

11.  How  will  you  insure  anticipated  changes  during  the  life  cycle  will  not  exceed 
computer  memory,  timing,  and  input/output  capacity? 

12.  Will  one  of  the  High  Order  Languages  in  DoD  Instruction  5000.31  be  used  for 
programming?  If  not,  why  not?  Has  a  formal  waiver  been  issued?  What  percentage 
of  the  software  will  ultimately  be  written  in  assembly  language? 

13.  What  configuration  control  techniques  will  be  used  for  software?  For  hardware? 

14.  Will  vendor-developed  support  software  be  used?  Will  the  government  receive 
copies  of  the  software  for  later  use? 

15.  Will  any  Data  Processing  Activities  be  required  for  life  cycle  support  of  the  system 
or  any  of  its  subsystems? 
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Tradeoff  Issues 


1.  What  tradeoffs  will  be  made  between  the  embedded  computer  and  other  methods  of 
meeting  the  system  requirements  (alternative  system  architectural  approaches)? 

2.  What  criteria  will  be  used  to  determine  whether  or  not  more  than  one  processor  will 
be  used  in  the  system?  How  will  the  partitioning  of  system  software  among 
processors  be  determined?  What  network  architecture  and  intercommunication 
protocal  standards  will  be  employed  (e.g,  MIL-STD‘-1553B)? 

3.  How  will  hardware/software/firmware  tradeoffs  be  made? 

4.  How  will  the  processor  architecture  be  determined? 

5.  If  the  decision  to  use  a  microprocessor  has  been  made,  what  criteria  will  be  used  to 
determine  whether  a  fixed  architecture  or  a  bit-slice  microprocessor  will  be  used? 
Is  the  selected  microprocessor  MlL-qualified?  If  not,  must  it  be  to  meet  stated 
requirements?  Will  the  microprocessor  be  logistically  supportable  over  the  system 
life  cycle? 

6.  How  will  the  processor  memory  capacity  be  determined? 

7.  How  will  timing  requirements  be  determined? 

8.  How  will  safety  margins  and  growth  capacities  for  memory,  processor  time,  and 
input/output  capabilities  be  determined?  How  will  these  resources  be  partitioned? 

9.  Will  off-line  software  support  be  required?  If  so,  what  host  computer  will  be  used? 
What  is  the  availability  of  the  host  computer?  What  support  software  is  available  on 
the  host  computer? 

10.  How  will  tradeoffs  between  contractor  versus  government  support  be  made? 

11.  How  will  the  team  that  participated  in  the  original  concepts  studies  be  maintained 
intact  for  tradeoff  studies? 

12.  How  are  operations  and  support  personnel  involved  in  tradeoff  decisions? 


Use  of  Existing  Hardware  and  Software 


1.  Will  one  of  the  DoD-approved  Instruction  Set  Architectures  be  used?  If  not,  why 
not? 

2.  What  new  technology  (computer,  sensor,  and  control)  must  be  developed  or  utilized? 
What  are  the  risks  in  such  a  development  effort? 

3.  What  special  tasks  must  be  performed  in  the  demonstration  and  validation  phase  to 
perfect  new  technologies? 

4.  How  much  system  design  can  be  obtained  "off-the-shelf”  from  previous  systems? 

5.  Which  existing  operational  application  and  software  support  packages  will  be 
utilized?  Are  the  application  programs  operational  on  the  proposed  computer?  If 
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not,  what  are  the  major  hardware/software  differences?  To  what  extent  have  the 
contractor’s  personnel  used  these  packages  previously? 


Acquisition  Strategy 

!•  How  will  source  selection  for  embedded  computer  hardware  be  made?  Who  will 
perform  the  evaluation  of  contractor  proposals?  What  are  embedded-computer- 
resources-oriented  source  selection  criteria? 

2*  How  will  competition  be  maintained  as  far  as  practical  during  system  acquisition*? 

3.  What  hardware  and/or  software  will  be  Government  Furnished  Equipment  (GFE)? 
What  hardware  and/or  software  will  be  Contractor  Furnished  Equipment  (CFE)? 

4.  How  were  the  percentages  of  GFE  and  CFE  determined?  If  there  is  a  mix  of  GFE 
and  CFE,  who  is  responsible  for  solving  system  integration  problems? 

5.  Which  devices  have  or  will  be  developed  by  other  Program  Offices?  How  will  the 
split  re^onsibilities  be  handled? 

6.  Wha,t  conseiderations  have  been  or  are  being  made  for  foreign  procurement? 

7-  When  and  where  will  the  final  acceptance  of  the  embedded  computer  resources  be 

made?  Who  will  determine  whether  the  system  is  acceptable? 

%  How  will  life  cycle  costs  be  developed  and  used  in  determining  the  best  acquisition 
strategy? 

10.  Will  commercial  computer  resources  be  acquired  for  the  system?  Is  approval  from 
Government  Services  Agency  required  for  any  of  the  computer  hardware? 


Possible  Future  Problem  Areas 


1.  Has  preliminary  systems  analysis  been  performed?  What  hardware  and/or  software 
problems  areas  were  discovered?  How  will  these  problems  be  solved  in  the 
demonstration  and  validation  phase? 

2.  What  critical  areas  must  be  resolved  during  the  demonstration  and  validation  phase? 
How? 

3.  Do  you  envision  other  risky  areas?  Wnat  are  your  plans  to  resolve  anticipated 
problems? 
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SECTION  III 


MILESTONE  II  (FULL-SCALE  DEVELOPMENT  DECISION) 


Milestone  II  is  reached  when  the  demonstration  and  validation  activity  has  been 
completed  and  a  recommendation  on  the  preferred  systems  for  full-scale  development  can 
be  made* 


General  Issues 


1.  What  are  the  present  problems  and  the  plans  for  resolving  them? 

2.  How  do  you  know  present  life  cycle  costs  and  time  estimates  are  sound? 

3.  What  is  the  computer  resource  budget  for  full-scale  engineering  development?  Of 
the  total  computer  resources  to  be  spent  during  this  phase,  what  percentage  will  be 
used  for  design,  for  coding,  and  for  testing  of  computer  software?  What  have  these 
percentages  been  for  the  contractor  in  the  past? 

4.  Have  the  acquisition  strategy  decisions  that  were  previously  made  been  reviewed? 
(Refer  to  Milestone  I  Acquisition  Strategy  questions.)  Are  any  acquisition  strategy 
issues  still  unresolved?  If  so,  when  will  they  be  resolved? 

5.  Have  all  Program  Manager’s  Staff  questions  from  Milestone  I  been  be  answered? 


Operational  Requirements 


1.  Have  the  system  operational  requirements  changed  since  Milestone  I?  Are  they  now 
stabilized? 

2.  How  were  the  requirements  for  computer  resources,  including  software  and  its 
support  documentation,  validated? 

3.  How  was  risk  analysis  performed? 

4.  How  will  you  insure  that  the  planned  computer  resources  will  meet  stated 
operational  requirements? 

5.  How  will  future  changes  to  computer  hardware  and  software  requirements  be  made? 
What  agency  will  be  responsible  for  making  the  changes? 


Life  Cycle  Management 


1. 


Which  Milestone  1  Life  Cycle  Management  questions  are  still  unanswered?  When  will 
the  answers  be  known? 


2. 


Has  a  Computer  Resources  Management  Plan  been  written?  By  whom?  Has  it  been 
approved?  How  and  when  will  the  plan  be  updated? 


3.  What  are  the  milestones  of  the  Computer  Resources  Management  Plan?  What 
criteria  will  be  used  to  measure  their  attainment? 

4.  What  steps  have  been  planned  for  the  software  ^turnove*"**  from  the  contractor  to  the 
government  and  from  the  acquisition  command  to  the  using  command? 

5.  How  will  the  computer  resources  be  integrated  into  the  total  system? 

6.  How  will  the  overall  system  quality  be  determined? 

7.  What  is  the  involvement  of  the  Software  Support  Activity  during  the  software 
development? 

8.  How  were  personnel  and  training  requirements  for  supporting  computer  resources 
determined? 

9.  How  can  you  demonstrate  sufficient  memory  and  timing  growth  capacity  have  been 
incorporated  in  the  system  design? 

10.  What  software  is  contract  deliverable?  Is  ail  unique  support  software  deliverable? 
If  not,  why  not? 

11.  What  software  documentation  is  contract  deliverable? 

12.  What  integrated  support  resources  are  contract  deliverable? 

13.  What  role  should  contractor  warranties  have? 

14.  How  have  producibility  and  production  readiness  been  considered?  If  they  have  not 
been,  when  will  these  disciplines  be  evaluated  for  adequacy? 


Tradeoff  Issues 


1.  How  were  tradeoff  decisions  made?  (Refer  to  Milestone  I  Tradeoff  Issues 
questions.) 

2.  Did  the  user  team  that  wrote  the  original  operational  requirements  assist  in  cost 
versus  capabilities  tradeoff?  If  not,  how  were  these  tradeoffs  evaluated? 


Project  Control 


1.  What  management  procedures  will  be  used  to  control  software  development,  cost 
and  schedule.  Are  maintenance  and  logistic  costs  and  scheduling  included? 

2.  What  milestones  in  the  Computer  Resources  Management  Plan  will  be  used  to 
control  hardware  and  software  development? 
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3.  Will  there  be  any  parallel  software  development  efforts?  If  so,  how  will  they  be 
controlled?  What  management  procedures  will  be  used  to  insure  adequate  visibility 
into  the  progress  of  subcontractors? 

4.  Has  the  use  of  an  independent  contractor  for  assessment  of  software  progress  been 
considered? 

3.  How  will  interface  control  (both  intersystem  and  intrasystem)  be  handled? 


Development  Contract 


1.  Will  the  acquisition  take  place  in  accordance  with  DoD  Directive  4105.55  (Public 
Law  89-306;  the  Brook*s  Act)?  Why  or  why  not? 

2.  Which  type  of  contract  will  be  employed  for  the  software  development?  Why? 

3.  How  will  the  contractor  be  tasked  for  software  and  software  support  items? 

4.  What  provisions  have  been  made  to  supply  the  contracting  office  with  adequate 
technical  information  to  write  a  development  contract? 

5.  What  will  be  the  software-related  contractor  incentives? 

6.  How  will  the  contract  prevent  minimizing  of  hardware  at  the  expense  of  software? 
What  are  the  contract  incentives  relating  to  computer  resources? 

7.  Is  all  software  listed  as  Computer  Program  Configuration  Items?  Which  software  is 
not  deliverable? 

8.  Is  all  support  software  listed  as  deliverable?  Is  any  proprietary?  If  so,  how  will  this 
be  handled? 

9.  Is  there  a  software  Design- to-Cost  goal?  How  will  progress  toward  this  goal  be 
measured? 

10.  What  software  documentation  is  contract-deliverable?  How  was  the  amount  of 
documentation  needed  determined? 


Testing 


1.  When  will  the  system  and  program  designs  be  baselined? 

2.  How  will  software  testing  be  performed?  What  levels  of  testing  will  be  employed? 
Will  an  independent  analysis  and  evaluation  be  accomplished? 

3.  How  will  you  insure  the  test  data  is  representative  of  the  total  range  of  data  and 
operational  conditions  that  the  system  might  encounter? 


4. 


Are  the  software  module  test  plans  and  software  module  test  procedures  adequate? 


5.  How  will  testing  be  used  to  clearly  identify  deficiencies  as  software  or  hardware 
related?  How  will  the  determination  of  whether  errors  are  caused  by  hardware  or 
software  be  made?  How  will  regression  test’  g  be  performed? 

6.  Are  **test  beds”  or  ”hot  benches”  required  to  adequately  test  software?  Will  they 
become  government  property  after  testing  is  complete''  If  not,  does  the  government 
have  equivalent  integration  and  testing  facilities  available?  What  ”test  bed” 
documentation  is  listed  as  a  contract  deliverable  item(s)? 

7.  How  will  software  modules  be  interfaced  with  one  another?  How  will  these 
interfaces  be  tested?  How  will  software  be  integrated  and  tested  as  part  of  the 
system? 

8.  What  critical  questions  and  areas  of  risk  still  need  resolving  by  testing?  What  are 
the  test  plans  and  milestones  for  resolving  these  problems? 

9.  How  will  test-related  documentation  and  media  be  maintained  to  allow  repeatability 
of  tests?  How  will  support  documentation  be  maintained  to  allow  traceability? 

10.  What  test  and  calibration  software  douementation  and  media  are  listed  as  contract 
deliverables? 

11.  How  will  verification  and  validation  be  performed?  Who  will  perform  it? 

Software  Quality,  Reliability,  and  Maintainability 


1.  How  will  you  determine  that  quality,  reliability,  and  maintainability  goals  and 
subsequent  test  standards  are  cost  effective  and  the  minimum  essential? 

2.  Is  one  of  the  High  Order  Languages  in  DoD  Instruction  5000.31  being  used  for 
programming?  If  not,  why  not?  What  is  the  estimated  percentage  of  the  software 
that  will  be  written  in  assembly  language? 

3.  How  will  you  assure  the  software  architecture  will  be  modular? 

4.  How  will  you  assure  ”top-down”  software  development  methodology  and  structured 
programming  will  be  used? 

5.  What  programming  standards  and  conventions  will  be  used?  How  will  they  be 
enforced? 

6.  When  will  the  Data  Item  Index  be  prepared  and  how  will  it  be  updated?  How  will  you 
insure  the  documentation  will  be  adequate  for  life  cycle  maintenance? 

7.  Which  automatic  debugging  tools  will  be  used  during  program  development?  Were 
they  developed  during  the  program?  Are  they  deliverable? 

8.  How  will  error  data  be  defined,  collected,  analyzed,  and  reported? 

9.  How  will  the  software  be  integrated  with  the  hardware  during  full-scale  engineering 
development? 

10.  How  will  software  be  documented  as  it  proceeds  from  concept  to  design  to  the  final 
operational  system? 
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11.  How  will  the  software  be  supported  in  the  field?  What  hardware  and  software  will 
be  needed  for  the  support  base?  How  will  it  be  procured? 

12.  Will  Automatic  Test  Pattern  Generators  be  used  for  support?  If  so,  are  they 
proprietary?  How  will  they  be  maintained?  What  support  documentation  is  contract 
deliverable?  How  will  it  be  validated? 


Miscellaneous  Issues 


1.  What  has  the  contractor  done  of  a  similar  nature  in  the  past?  What  were  his 
successes  and  failures?  What  is  he  doing  to  eliminate  past  problem  areas? 

2.  What  method  was  used  for  estimating  software  life  cycle  costs?  When  was  the 
original  estimate  made?  How  often  has  the  estimate  been  revised?  What  have  been 
the  accuracy  of  previous  estimates? 

3.  What  problems  must  be  solved  prior  to  the  Milestone  III  decision  point  that  have  not 
already  been  discussed?  What  is  your  plan  for  solving  them? 

4.  Must  data  or  programs  in  the  system  be  secure?  If  so,  at  what  level?  What  security 
issues  must  be  resolved? 

5.  What  is  the  government's  mechanism  to  make  an  independent  assessment  of  the 
software? 
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SECTION  IV 


MILESTONE  III  (PRODUCTION  AND  DEPLOYMENT  DECISION) 


The  Milestone  III  decision  point  is  reached  when  a  production  recommendation  for 
the  system  can  be  made. 


General  Issues 


1.  Are  the  original  operational  requirements  still  valid?  How  can  this  be  proven? 

2.  What  is  the  status  of  producibility  and  production  readiness? 


Present  Status 


1.  What  are  the  results  of  the  latest  series  of  operational  tests  (on  the  entire  weapon 
system)?  Where  are  the  current  tests  in  relationship  to  the  overall  test  plan? 

2.  What  impact  will  the  need  for  subsystem  changes  discovered  during  testing  and 
evaluation  of  the  overall  weapon  system  have  on  embedded  computer  hardware  and 
software  and  on  spares  and  spare  parts  quantitative  determinations? 

3.  Are  any  software  modules  incomplete?  Which  modules  and  associated  hardware  are 
involved?  What  is  the  extent  of  incompleteness  and  the  schedule  for  completion? 

4.  What  is  the  profile  of  the  last  three  months  of  Discrepancy  forms  and  Software 
Change  Requests?  How  many  discrepancies  are  still  to  be  corrected?  How  is  the 
error  data  collected  and  analyzed? 

5.  How  much  of  the  recent  software  change  activity  has  been  due  to  program  errors 
and  how  much  has  been  due  to  change  in  requirements?  Were  changes  in 
requirements  due  to  increased  or  decreased  requirement?  Who  has  the  authority  to 
change  software  requirements? 

6.  How  has  delivered  code  been  verified  to  conform  to  original  software  design?  Who 
prepared  test  data  for  the  validation?  How  has  delivered  code  been  shown  to  satisfy 
original  operational  requirements?  How  was  the  support  documentation  validated? 

7.  How  was  hardware/software  integration  and  validation  performed? 


Life  Cycle  Management 


1.  Are  any  Life  Cycle  Management  questions  from  Milestone  II  still  unanswered?  Why? 
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2.  What  changes  have  been  made  to  the  Computer  Resources  Management  Plan  since 
Milestone  II?  Is  the  development  schedule  in  accordance  with  the  plan?  What 
impact  will  slippages  have  on  the  entire  system  during  production  and  deployment? 

3.  When  will  the  software  "turnover"  from  the  contractor  to  the  government  take 
place?  What  steps  must  take  place  before  the  turnover?  Is  the  procuring  command 
prepared  to  turnover  the  software  to  the  using  command  and  the  Software  Support 
Activity? 

4.  Who  will  provide  software  support  during  deployment  of  the  system?  What 
equipment,  facilities,  personnel,  software,  etc.  will  be  required  in  the  support  base? 
How  will  future  modifications  to  baseline  software  be  handled? 

5.  What  will  be  the  impact  of  anticipated  software  improvements?  What  are  the 
anticipated  improvements  and  which  areas  of  the  system  will  be  involved? 

6.  What  is  the  general  logic  flow  for  the  system?  How  would  government  personnel  go 
from  the  general  flow  chart  to  the  source  coding?  Is  a  Data  Item  Index  a  deliverable 
item? 

7.  How  is  the  software  compatible  with  operation/iogistics  concepts? 


Production  Issues 

1.  How  was  software  maturity  (versus  design  maturity)  measured  during  development? 

2.  What  are  the  embedded  computer  related  costs  and  schedule  risks?  How  were  they 
determined? 

3.  How  can  the  completion  of  software  development  be  shown  quantitatively? 


Miscellaneous  Issues 


1.  How  will  changes  to  the  computer  hardware  and  software  be  made  after 
deployment?  How  will  these  changes  be  funded?  How  will  system  configuration  be 
controlled? 

2.  Under  what  conditions  will  a  formal  Operational  Test  and  Evaluation  be  required  for 
major  computer  hardware  and/or  software  changes  made  after  deployment  of  the 
weapon  system?  How  will  reliability  of  the  changed  system  be  demonstrated?  How 
will  the  testing  be  funded? 

3.  In  the  event  that  quality,  reliability,  and  maintainability  are  inadequate,  how  will 
they  be  improved? 

4.  Has  the  original  acquisition  strategy  been  reviewed  and  found  to  be  adequate?  What 
alternatives  were  considered? 

5.  Are  there  any  "lessons  learned"  that  should  be  passed  on?  What  process  will  be 
used? 
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SECTION  V 

EMBEDDED  COMPUTER  RESOURCES  DEFINITIONS 


COMMERCIALLY  AVAILABLE*  Offered  for  sale  to  the  general  public  and/or  industry  at 
established  catalog  or  market  prices.  (As  compared  to  Specially  Designed.) 

COMPUTER  RESOURCES.  The  totality  of: 

a.  Computer  Data.  Basic  elements  of  information  used  by  computer  hardware  in 
responding  to  a  computer  program. 

b.  Computer  Hardware.  Devices  capable  of  accepting  and  storing  computer 
data,  executing  a  systematic  sequence  of  operations  on  computer  data,  or 
producing  control  outputs.  Such  devices  can  perform  substantial  interpreta¬ 
tion,  computation,  communication,  control,  and  other  logical  functions. 

c.  Computer  Program.  A  series  of  instructions  or  statements  in  a  form 
acceptable  to  an  electronic  computer  designed  to  cause  the  computer  to 
execute  an  operation  or  series  of  operations.  Computer  programs  include 
software  such  as  operating  systems,  assemblers,  compilers,  interpreters,  data 
management  system,  utility  programs,  and  maintenance/diagnostic  programs. 
They  also  include  application  programs  such  as  payroll,  inventory  control, 
operational  flights,  strategic,  tactical,  automatic  test,  crew  simulator,  and 
engineering  analysis  programs.  Computer  programs  may  be  either  machine 
dep>endent  or  machine  independent,  and  may  be  general  purpose  in  nature  or  be 
designed  to  satisfy  the  requirements  of  a  specialized  process  of  a  particular 
user. 

d.  Computer  Resource  Documentation.  Printed  or  machine  readable 

description  of  computer  programs,  computer  hardware,  or  other  computer 
resource  assets  necessary  to  support  design,  development,  test,  and  life  cycle 
maintenance. 

e.  Computer  Personnel.  AH  Government  personnel,  both  civilian  and  military, 
who  are  identified  with  computer  resource  functions. 

f.  Computer  Supplies.  Items  designed  specifically  for  use  with  computer 

hardware,  such  as  magnetic  or  paper  tape,  removable  magnetic  disk  packs, 
punch  cards,  printer  paper,  and  ribbons. 

g.  Computer  Contractual  Services.  All  ser vices  in  support  of  a  computer 
requirement  and  obtained  on  a  contractual  basis,  including  but  not  limited  to: 
machine  time,  operations,  maintenance,  and  engineering  modifications; 
training;  and  professional  services  such  as  programming,  systems  analysis, 
systems  design,  systems  engineering,  and  consulting. 

h.  Computer  Software.  A  collection  of  associated  computer  programs  and 

computer  data  required  to  enable  the  computer  equipment  to  perform 
computational  or  control  functions.  NOTE:  It  is  the  abstract  contents  of  tape, 
discs,  card  decks,  and  firmware. 

(1)  Support  Software.  Any  software  designed  to  support  the  development 
maintenance  and  modification  of  other  software. 
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(2)  Utility  Program*  A  developmental  tool  necessary  for  the  generation  of 
the  operational  and  support  programs. 

(3)  Test  Software.  Software  that  is  utilized  in  the  testing  of  design  and 
implementation  of  hardware  and  other  software.  NOTE;  Testing  is 
conducted  to  ensure  that  hardware  and/or  software  adhere  to  design 
specifications,  functional  specifications,  and  performance  specifications. 

(4)  Operational  Software.  Programs  required  to  operate  the  system.  These 
programs  are  loaded  and  run  in  the  computer  equipment  during  system 
operation  and  can  include  the  following  functions:  executive/supervisor, 
functional/application,  and  input/output. 

CONFIGURATION  ITEM  (Cl).  An  aggregation  of  hardware/computer  software,  or  any 
of  its  discrete  portions,  which  satisfies  an  end-use  function  and  is  designated  by  the 
Government  for  configuration  management.,  NOTE:  In  reference  to  computer  software, 
the  term  Computer  Program  Configuration  Item  (CPCI)  is  used  interchangeably. 

COMPUTER  PROGRAM  CONFIGURATION  ITEM  (CPCI).  See  Configuration  Item. 

DEFENSE  SYSTEM.  A  Defense  System  is  a  major  system  as  designed  by  the  Secretary 
of  Defense  or  as  managed  under  the  provisions  of  DoD  Directive  5000.1  (Major  System 
Acquisition)  and  DoD  Instruction  5000.2  (Major  System  Acquisition  Procedures)  or  a  less- 
than-major  system  managed  by  the  components  under  similar  review  processes.  Defense 
systems  are  associated  with  the  conduct  of  the  National  Security  Mission  of  the  DoD  as 
contrasted  with  the  administration  of  the  Department  and  may  include  dedicated  support 
functions  such  as  automatic  test,  training  simulators,  automated  materials  handling,  etc. 

DIRECT  SUPPORT.  Includes  those  functions  such  as  specialized  training,  testing,  or 
software  support  which  are  dedicated  to  the  operation  and  maintenance  of  a  system 
throughout  its  life  cycle.  Excluded  are  ADPE  functions  such  as  management  information 
systems,  configuration  management,  or  logistics  systems. 

EMBEDDED  COMPUTER.  A  computer  incorporated  as  an  integral  part  of,  dedicated  to, 
or  required  for  direct  support  of,  or  for  the  upgrading  or  modification  of,  major  or  less- 
than-major  systems. 

FIRMWARE.  Any  level  of  computer  program  and/or  computer  data  that  cannot  be 
readily  modified  under  computer  program  control;  that  is,  read  only.  The  definition  also 
applies  to  read  only  digital  data  that  may  be  used  by  electronic  devices  other  than  digital 
computers. 

HARDWARE  INTENSIVE.  Those  computer  applications  in  which  the  function  is  fixed 
and  hence,  the  computer  program  is  not  expected  to  be  changed  (after  development  and 
test)  for  the  lifetime  of  the  physical  component  in  which  it  is  embedded. 

Some  of  the  factors  which  may  be  considered  in  determining  whether  an  application 
program  is  likely  to  change  are:  the  computer  program  size;  the  quantities  associated 
with  application  system  in  which  a  computer  or  processor  is  embedded;  the  practice  of 
making  changes  only  to  newly-produced  units  rather  than  retrofit  to  fielded  units;  the 
ratio  of  expected  software  life  cycle  cost  to  expected  system  life  cycle  cost;  and  the 
implementation  of  programs  in  read-only  memory. 
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HIGH  ORDER  LANGUAGE  (HOL)*  An  HOL  is  a  language  used  to  communicate 
computational  or  procedural  processes  to  a  computer.  An  HOL  provides  compression  of 
computer  instructions  such  that  one  HOL  statement  or  expression  may  cause  many 
machine  language  instructions  to  be  executed,  and  provides  declarative  and  descriptive 
information  that  is  not  readily  derivable  from  the  corresponding  sequence  of  machine 
instructions.  An  HOL  is  generally  machine-independent  although  its  implementations  may 
not  be. 

INSTRUCTION  SET  ARCHITECTURE  (ISA).  The  attributes  of  a  digital  computer  or 
processor  as  might  be  seen  by  a  machine  (assembly)  language  programmer,  i.e.,  the 
conceptual  structure  and  functional  behavior  as  distinct  from  the  organization  of  the  data 
flow  and  controls,  logic  design,  and  physical  implementation. 

This  definition  includes  the  processor  and  input/output  instruction  sets,  their 
formats,  operation  codes,  and  addressing  modes;  the  memory  management  and  partitioning 
if  accessible  to  the  machine  language  programmer;  the  speed  of  accessible  clocks;  the 
interrupt  structure;  and  the  manner  of  use  and  format  of  all  registers  and  memory 
locations  that  may  be  directly  manipulated  or  tested  by  a  machine  language  program. 

This  definition  excludes  the  time  or  speed  of  any  operation,  the  internal  computer 
partitioning,  the  electrical  and  physical  organization,  the  circuits  and  components  of  the 
computer,  the  manufacturing  technology,  the  memory  organization,  the  memory  cycle 
time,  and  the  memory  bus  widths. 

INTEGRAL.  Dedicated  and  essential  to  the  specific  functional  task  for  which  the 
higher  order  system  was  designed. 

LANGUAGE  CONTROL  AGENT.  The  organization  responsible  for  ensuring  stability  and 
configuration  of  the  specified  DoD-approved  High  Order  Language.  The  Language  Control 
Agent  controls  changes  to  the  language  standard  and  ensures  changes  receive  appropriate 
review. 

LESS-THAN-MA3QR  SYSTEM.  Any  system  not  designated  as  a  major  system  by  the 
Secretary  of  Defense  but  managed  in  accordance  with  the  principles  of  DoDD  5000.1  and 
DoDI  5000.2. 

MACHINE  ORIENTED  LANGUAGE  (MOL).  MOLs  including  Assembly  Languages  are 
machine-dependent  languages  used  to  communicate  programs  on  a  one-for-one  basis  with 
machine  language  instruction. 

MAJOR  SYSTEM.  A  system  so  designated  by  the  Secretary  of  Defense  and  managed 
under  DoD  Directive  5000.1  and  DoD  Instruction  5000.2. 

SOFTWARE  ENGINEERING.  The  branch  of  science  and  technology  which  deals  with 
the  design,  development,  documentation,  implementation,  test,  evaluation,  verification, 
rperational  use,  and  maintenance  of  computer  software  throughout  its  life  cycle. 

SPECIALLY  DESIGNED.  Government  specified  and  not  commercially  available.  Ex¬ 
cludes  specially  configured.  (As  compared  to  Commercially  Available.) 

SOFTWARE  MAINTENANCE.  Error  correction  associated  with  incorrect  imnlementa- 
tion  of  software  as  defined  in  the  specifications  or  those  due  to  programming  errors. 
Software  maintenance  does  not  include  modifications  in  support  of  changing  needs  or 
requirements. 
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SOFTWARE  MODIFICATION, 
or  requirements. 


Software  changes  made  to  accommodate  changing  needs 


VALIDATION.  The  evaluation,  integration,  and  test  activities  carried  out  at  the  system 
level  to  ensure  that  the  finally-developed  system  satisfies  the  mission  requirements  set 
down  as  performance  cind  design  criteria  in  the  system  specification. 

VERIFICATION  (OF  COMPUTER  PROGRAMS).  The  interactive  process  of  determining 
whether  the  product  of  each  step  of  the  Cl  development  process  fulfills  ail  of  the 
requirements  levied  by  the  previous  step.  Examples  of  this  process  are: 

a.  System  engineering  analytical  activities  carried  out  to  ensure  that  the  Cl 
Development  Specifications  reflect  the  performance  requirements  allocated 
from  the  System  Specification. 

b.  Design  evaluation  activities  carrier  out  to  ensure  that  the  Cl  design  continues 
to  meet  the  requirements  of  the  Development  Specification  as  the  design 
proceeds  to  greater  levels  of  detail. 

c.  Informal  testing  of  the  Cl  and  its  components. 

d.  Formal  qualification  testing  of  the  Cl  to  verify  that  the  Cl  fulfills  the 
requirements  of  the  Development  Specification. 

Definitions  for  other  terms  can  be  found  in  EIA  Configuration  Management  Bulletin 
No.  4-lA  and  the  DACS  Glossary  (refer  to  References  section). 


EMBEDDED  COMPUTER  REGULATIONS  &  STANDARDS 


EMBEDDED  COMPUTER  RESOURCES  REFERENCES 


DoD  Directives,  Instructions  and  Standards 

1.  DoDD  4105.55,  "Selection  and  Acquisition  of  Automatic  Data  Processing 
Resources,"  dated  19  May  1972,  inch  Changes  1,  2,  and  3 

2.  DoDD  4120.3,  "Defense  Standardization  and  Specification  Program,"  dated  10 
February  1979 

3.  DoDD  4120.18,  "Metric  System  of  Measurement,"  dated  28  3anuary  1980 

4.  DoDI  4120.20,  "Development  and  Use  of  Non-Government  Specifications  and 
Standards,"  dated  28  December  1976 

5.  DoDD  4120.21,  "Specifications  and  Standards  Application,"  dated  9  April  1977 

6.  DoDD  4155.1,  "Quality  Program,"  dated  10  August  1978,  inch  Change  1 

7.  DoDD  5000.1,  "Major  System  Acquisitions,"  dated  19  March  1980 

8.  DoDI  5000.2,  "Major  System  Acquisition  Procedures,"  dated  19  March  1980 

9.  DoDD  5000.3,  "Test  and  Evaluation,"  dated  26  December  1979 

10.  DoDD  5000.28,  "Design  to  Cost,"  dated  23  May  1975 

11.  DoDD  5000.29,  "Management  of  Computer  Resources  in  Major  Defense 
Systems,"  dated  26  April  1976,  inch  Change  1  (being  revised) 

12.  DoDI  5000.31,  "Interim  List  of  DoD  Approved  High  Order  Programming 
Languages  (HOLs),"  dated  24  November  1976  (Revision  in  final  coordination) 

13.  DoDD  5000.37,  "Acquisition  and  Distribution  of  Commercial  Products 
(ADCP),"  dated  29  September  1978 

14  DoDD  5000.39,  "Acquisition  and  Management  of  Integrated  Logistic  Support 
for  Systems  and  Equipment,"  dated  17  January  1980 

15.  DoDD  5000.40,  "Reliability  aiid  Maintainability,"  dated  8  July  1980 

16.  DoDI  5000. 5x,  "Instruction  Set  Architecture  (ISA)  Standardization  Policy  for 
Embedded  Computers,"  (In  final  coordination) 

17.  DoDD  5010.12,  "Management  of  Technical  Data,"  dated  5  December  1968,  incl. 
Change  I 

18.  DoDD  5010.19,  "Configuration  Management,"  dated  1  May  1979 

19.  DoDD  5100.40,  "Responsibility  for  the  Administration  of  the  DoD  Automatic 
Data  Processing  Program,"  dated  19  August  1975,  incl.  Change  I 
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20.  DoDD  5200.28,  "Security  Requirements  for  Automatic  Data  Processing  (ADP) 
Systems,"  dated  18  December  1972,  incl.  Change  2 

21.  DoDD  7920.1,  "Life  Cycle  Management  of  Automated  Information  Systems 
(AIS),"  dated  17  October  1978 

22.  DoDI  7920.2,  "Major  Automated  Information  Systems  Approval  Process,"  dated 
20  October  1978 

Army  Documents 

1.  Assistant  Secretary  of  the  Army  Policy  Letter,  subject:  "Standardization  of 
Embedded  Computer  Resources,"  dated  1  July  1980 

2.  AR  18-1,  "Army  Automation  Management,"  dated  15  August  1980 

3.  AR  18-12,  "Catalog  of  Standard  Data  Elements  and  Codes,"  dated  29  March 
1974 

4.  AR  70-1,  "Army  Research,  Development,  and  Acquisition,"  dated  1  May  1975 

5.  AR  70-10,  "Test  and  Evaluation  during  Development  and  Acquisition  of 
Materiel,"  dated  29  August  1975 

6.  DARCOM  Reg.  70-16,  "Management  of  Computer  Resources  in  Battlefield 
Automated  Systems,"  dated  16  July  1979 

7.  AR  70-27,  "Outline  Development  Plan/Development  Plan/ Army  Program 
Memorandum/Defense  Program  Memorandum/Decision  Coordinating  Paper," 
dated  17  March  1975 

8.  AR  70-29,  "Production  Testing  of  DSA-managed  Items,"  dated  27  May  1969 

9.  AR  70-37,  "Configuration  Management,"  dated  1  July  1974 

10.  AR  70-38,  "Research,  Development,  Test,  and  Evaluation  of  Materiel  for 
Extreme  Climatic  Conditions,"  dated  5  May  1969 

11.  AR  71-3,  "User  Testing,"  dated  8  March  1977 

12.  AR  310-3,  "Preparation,  Coordination,  and  Approval  of  Department  of  Army 
Publications,"  dated  20  December  1968 

13.  AR  310-25,  "Dictionary  of  US  Army  Terms,"  dated  15  September  1975 

14.  AR  380-380,  "Automated  Systems  Security,"  dated  14  October  1977 

15.  AR  700-127,  "Integrated  Logistics  Support,"  dated  11  April  1975 

16.  AR  702-2,  "Uniform  Quality  Control  System,"  dated  3  December  1970 


17.  AR  702-3,  "Army  Materiel  Reliability,  Availability,  and  Maintainability,"  dated 
15  November  1976 


18.  AR  702-4,  "Procurement  Quality  Assurance,"  dated  3  August  1976 


19.  AR  750-1,  "Army  Materiel  Maintenance  Concepts  and  Policies,"  dated  1  April 
1978 

20.  AR  1000-1,  "Basic  Policies  for  System  Acquisition,"  dated  1  May  1981 

21.  Technical  Bulletin  18-115,  "Army  Information  Processing  Standards  (AIPS)," 
dated  3  July  1980 

C.  Navy  Documents 

1.  SECNAVINST  3560,1,  "Tactical  Digital  Systems  Documentation  Standards," 
dated  8  August  1974 

2.  SECNAVINST  5000. lA,  "System  Acquisition  in  the  Department  of  the  Navy," 
dated  17  November  1978 

3.  SECNAVINST  5200.32,  "Management  of  Embedded  Computer  Resources  in  the 
Department  of  the  Navy  Systems,"  dated  11  June  1979 

4.  SECNAVINST  5231.1,  "Management  of  Automated  Data  Systems  Development," 
dated  25  February  1972 

5.  SECNAVINST  5233. lA,  C-1,  "Department  of  the  Navy  Automated  Data  System 
Documentation  Standards,"  dated  30  August  1974 

6.  WS-8506,  "Requirements  for  Digital  Computer  Program  Documentation,"  dated 
1  November  1971 

7.  TADSTAND  2,  "Standard  Specification  for  Tactical  Digital  Computer  Program 
Documentation,"  dated  1  November  1974 

8.  TADSTAND  3,  "Standard  Requirements  for  Inter-digital  Processor  Interface 
Documentation,"  dated  5  November  1974 

9.  TADSTAND  9,  "Software  Quality  Testing  Criteria  Standard  for  Tactical 
Digital  Systems,"  dated  18  August  1978 

10.  TADSTAND  A,  "Standard  definitions  for  Embedded  Computer  Resources  in 
Tactical  Digital  Systems,"  dated  2  July  1980 

11.  TADSTAND  B,  "Standard  Embedded  Computers,  Computer  Peripherals,  and 
Input/Output  Interfaces,"  dated  2  July  1980 

12.  TADSTAND  C,  "Computer  Programming  Language  Standardization  Policy  for 
Tactical  Digital  Systems,"  dated  2  July  1980 

13.  TADSTAND  D,  "Reserve  Capacity  Requirements  for  Tactical  Digital 
Systems,"  dated  2  July  1980 

D.  Air  Force  Documents 

1.  AFR  57-4,  "Modification  Program  Approval,"  dated  15  December  1977,  inch 
Change  1;  AFSC  Sup.  1,  dated  1  April  1974 


21 


2.  AFR  65-3,  "Configuration  Management,"  revised  1  September  1974;  AFSC  Sup. 
1,  dated  25  July  1975 

3.  AFR  80-14,  "Test  and  Evaluation,"  dated  19  3uly  1976;  AFSC  Sup.  1,  dated  3 
January  1977 

4.  AFR  122-9,  "The  Nuclear  Safety  Cross-Check  Analysis  and  Certification 
Program  for  Weapon  Systems  Software,"  dated  22  October  1976;  AFSC  Sup.  1, 
dated  22  March  1977 

5.  AFR  122-10,  "Nuclear  Weapon  System  Safety  Design  and  Evaluation  Criteria," 
dated  27  November  1978 

6.  AFR  300-8,  "Security  Requirements  for  Automatic  Data  Processing  Systems 
(ADPS),"  dated  3  June  1974 

7.  AFR  300-10,  "Computer  Programming  Languages,"  dated  15  December  1976 

8.  AFR  800-2,  "Acquisition  Program  Management,"  dated  14  November  1977 

9.  AFLCR  800-12,  "Acquisition  of  Support  Equipment,"  dated  20  May  1974 

10.  AFR  800-14,  V.I,  "Management  of  Computer  Resources  in  Systems,"  dated  12 
September  1975;  AFLC  Sup.  1,  dated  15  October  1976;  AFSC  Sup.  1,  dated  8 
August  1977;  ESD  Sup.  J,  dated  8  August  1977 

11.  AFR  800-14,  V.II,  "Acquisition  and  Support  Procedures  for  Computer  Resources 
in  Systems,"  dated  26  September  1975;  AFLC  Sup.  1,  dated  18  October  1976; 
ESD  Sup.  1,  dated  25  November  1975 

12.  AFR  800-19,  "System  or  Equipment  Turnover,"  dated  27  May  1975 

13.  AFLCR  800-21,  "Management  and  Support  Procedures  for  Computer  Resources 
Used  in  Defense  Systems,"  dated  4  January  1980 

14.  AFR  800-28,  "Air  Force  Policy  on  Avionics  Acquisition  and  Support,"  dated  11 
September  1978 

Standardization  Documents 

1.  DoD-STD-lOOC,  "Engineering  Drawing  Practices,"  revised  22  December  1978; 
Notice  1,  dated  30  April  1980 

2.  MIL-STD-109B,  "Quality  Assurance  Terms  and  Definitions,"  dated  4  April  1969 

3.  MIL-STD-143B,  "Order  of  Precedence  for  the  Selection  of  Standards  and 
Specifications,"  dated  12  November  1969 

4.  MIL- STD-470,  "Maintainability  Program  Requirements  (for  Systems  and  Equip¬ 
ment),"  dated  21  March  1966 

5.  DOD-STD-480A,  "Configuration  Control  -  Engineering  Changes,  Deviations  and 
Waivers,"  dated  12  April  1978 

6.  MIL-STD-481A,  "Configuration  Control  -  Engineering  Changes,  Deviations  and 
Waivers  (Short  Form),"  dated  18  October  1972 


7.  MIL-STD-482A,  '*Configuration  Status  Accounting  Data  Elements  and  Related 
Features,"  dated  1  April  1974 

8.  MIL- STD-483  (USAF),  "Configuration  Management  Practices  for  Systems, 
Equipment,  Munitions  and  Computer  Software,"  revised  1  June  1971;  Notice  2, 
dated  21  March  1979 

9.  MIL-STD-490,  "Specification  Practices,"  revised  18  May  1972 

10.  MIL-STD-721B,  "Definitions  of  Effectiveness  Terms  for  Reliability,  Maintain¬ 
ability,  Human  Factors  and  Safety,"  revised  10  March  1970 

11.  MIL-STD-756A,  "Reliability  Prediction,"  dated  15  May  1963 

12.  MIL-STD-757,  "Reliability  Evaluation  from  Demonstration  Data,"  dated  19 
June  1964 

13.  MIL-STD-785B,  "Reliability  Program  for  Systems  and  Equipment  Development 
and  Production,"  revised  15  September  1980 

14.  MIL-5TD-1472B,  "Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipments  and  Facilities,"  revised  10  May  1976;  Notice  2,  dated  10  May  1978 

15.  MIL-STD-1521A  (USAF),  "Technical  Reviews  and  Audits  for  Systems,  Equip¬ 
ments  and  Computer  Programs,"  dated  1  June  1976;  Notice  1,  dated  27 
September  1978 

16.  MIL-5TD-i553B,  "Aircraft  Internal  Time  Division  Command/Response  Multi¬ 
plex  Data  Bus,"  dated  21  September  1978;  Notice  1,  dated  12  February  1980 

17.  MIL-STD-1589B(USAF),  "JOVIAL  (J73),"  dated  6  June  1980 

18.  MIL-STD-1679  (NAVY),  "Weapon  System  Software  Development,"  dated  I 
December  1978 

19.  MIL-STD-1750A(USAF),  "Sixteen-Bit  Computer  Instruction  Set  Architecture," 
dated  2  July  1980 

20.  ^^IL-STD-1753,  "FORTRAN,  DoD  Supplement  to  American  National  Standard 
X3,9-1978,"  dated  9  November  1978 

21.  MIL-STD-18I5,  "Ada  Programming  Language,"  dated  10  December  1980 

22.  MIL-STD-1862,  "Instruction  Set  Architecture  for  the  Military  Computer 
Family,"  dated  28  May  1980 

23.  DoD  Standard  7935. 1-S,  "Automated  Data  Systems  Documentation  Standards," 
dated  13  September  1977 

24.  MIL-Q-9858A,  "Quality  Program  Requirements,"  dated  16  December  1963 

25.  MIL-S-52779A  (AD),  "Software  Quality  Assurance  Program  Requirements," 
dated  1  August  1979 
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26.  ANSI/IEEE  Std  416-78,  ^‘Standard  ATLAS  Test  Language** 

27.  FIPS  Pub  Il-i,  ''Dictionary  for  Information  Processing,**  dated  30  September 
1977 

28.  FIPS  Pub  24,  "Flowchart  Symbols  and  their  Usage  in  Information  Processing,** 
dated  30  June  1973 

29.  FIPS  Pub  30,  ’'Software  Summary  for  Describing  Computer  Programs  and 
Automated  Data  Systems,**  dated  30  June  1974 

30.  FIPS  Pub  41,  "Computer  Security  Guidelines  for  Implementing  the  Privacy  Act 
of  1974,"  dated  30  May  1975 

31.  '*CMS-24  Programmer's  Reference  Manuals,"  M-5049  and  M-5044  FCDSSA,  San 
Diego,  CA,  December  1978 

32.  **CMS-2M  Computer  Performance  Specification,"  NAVELEX  0967LP-598-2210, 
October  1978 

33.  '*SPL/i  Language  Reference  Manual,'*  5490-163;  EFrvjs,  NRL,  Washington,  DC 
F.  Guidebooks  and  Miscellaneous  References 

1.  ASD-TR-76-11,  "Management  Guide  to  Avionics  Software  Acquisition;  Vol.  I, 
An  Overview  of  Software  Development  and  Management,  (AD  A030591);  Vol.  II, 
Software  Acquisition  Process  (AD  A030592);  Vol.  Ill,  Summary  of  Software 
Related  Standards  and  Regulations  (AD  A030593);  Vol.  IV,  Technical  Aspects 
Relative  to  Software  Acquisition  (AD  A030594),"  June  1976 

2.  ASD-TR-78-6,  (AD  A058428),  "Engineering  Guide  to  Avionics  Software 

Acquisition;  Requirements,  Specifications,  and  Standards'* 

3.  ASD-TR-78-7,  (AD  A058429),  ''Engineering  Guide  to  Avionics  Software 

Acquisition:  Reviews  and  Audits" 

4.  ASD-TR-78-8,  (AD  A059068),  ''Airborne  Systems  Software  Acquisition 

Engineering  Guidebook  for  Quality  Assurance,"  November  1977 

5.  ESD-TR-75-85,  (AD  A016488),  "An  Air  Force  Guide  to  Monitoring  and 

Reporting  Software  Development  Status,"  September  1975 

6.  ESD-TR-75-9i,  (AD  A016401),  "Software  Acquisition  Management  Guidebook: 
Requirements,  Specifications,  and  Standards,"  October  1975 

7.  ESD-TR-75-365,  (AD  A020444),  "An  Air  Force  Guide  to  Contracting  for 
Software  Acquisition,"  January  1976 

8.  ESD-TR-76-159,  (AD  A027051),  "An  Air  Force  Guide  to  Software  Documenta¬ 
tion  Requirements,"  June  1976 

9.  ESD-TR-77-16,  (AD  A035924),  "Software  Acquisition  Management  Guidebook; 
Statement  of  Work  Preparation,"  January  1977 
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10.  ESD-TR-77-22,  (AD  A037115),  ’’Software  Acquisition  Management  Guidebook: 
Life  Cycle  Events,”  February  1977 

11.  ESD-TR-77-130,  (AD  A038234),  "Software  Acquisition  Management  Guidebook: 
Software  Development  and  Maintenance  Facilities,”  April  1977 

12.  ESD-TR-77-263,  (AD  A048577),  "Software  Acquisition  Management  Guidebook: 
Validation  and  Certification,”  August  1977 

13.  ESD-TR-77-254,  (AD  A047308),  ”An  Air  Force  Guide  to  Computer  Program 
Configuration  Management,”  August  1977 

14.  ESD-TR-77-255,  (AD  A047318),  "Software  Acquisition  Management  Guidebook: 
Software  Quality  Assurance,”  August  1977 

15.  ESD-TR-77-263,  (AD  A048577),  "Software  Acquisition  Management  Guidebook: 
Verification,"  August  1977 

16.  ESD-TR-77-326,  (AD  A053039),  "Software  Acquisition  Management  Guidebook: 
Validation  and  Certification,”  August  1977 

17.  ESD-TR-77-327,  (AD  A053040),  "Software  Acquisition  Management  Guidebook: 
Software  Maintenance,”  October  1977 

18.  ESD-TR-78-117,  (AD  A052567),  "Software  Acquisition  Management  Guidebook: 
Reviews  and  Audits,"  November  1977 

19.  ESD-TR-78-139,  (AD  A055573),  "An  Air  Force  Guide  to  the  Computer  Program 
Development  Specification,”  March  1978 

20.  ESD-TR-78-140,  (AD  A055574),  "Software  Acquisition  Management  Guidebook: 
Software  Cost  Estimation  and  Measurement,”  March  1978 

21.  ESD-TR-78-141,  (AD  A055575),  "Software  Acquisition  Management  Guidebook: 
Series  Overview,”  March  1978 

22.  "Tactical  Embedded  Computer  Software  Audit  Manual,”  dated  2  May  1980 
(available  from  HQ,  NAVMAT-08Y) 

23.  "EIA  Configuration  Management  Bulletin  No.  4-lA,  Configuration  Management 
for  Digital  Computer  Programs  (Definitions),"  (available  from  Electronic 
Industries  Association,  Engineering  Department;  2001  Eye  Street,  N.W., 
Washington,  DC  20006) 

24.  "The  DACS  Glossay,  A  Bibliography  of  Software  Engineering  Terms,”  October 
1979  (available  from  Data  and  Analysis  Center  for  Software,  RADC/ISISI, 
Griffiss  Air  Force  Base,  NY  13441) 

25.  Public  Law  89-306,  89th  Congress,  H.R.  4845,  dated  30  October  1965,  "Brook’s 
Bill” 
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Comments  on  Embedded  Computer  Resources  and  the  DSARC  Process  - 

A  Guidebook  (1981  Edition) 


_  General 

_  Specific  (Page _ ,  Paragraph  or  question  _ ) 

COMMENT/SUGGESTED  CHANGE  (Continue  on  extra  sheets  if  necessary.): 


REASON: 


ESSENTIAL  _  SUGGESTED 

Inform  me  when  the  present  guidebook  is  being  updated. 

NAME: _ 

ADDRESS: 


PHONE:  (Commercial) 
(Autovon) 


